1. Technical Field
The present invention relates to communication networks generally. More specifically, the present invention relates to a method and system for network time protocol forwarding.
2. Description of Related Art
In a communications network, the synchronization of time between network elements may be important in a variety of situations (e.g., stock market sale and buy orders and confirmation timestamps or other time-critical business transactions, network fault isolation, reporting and restoration, network monitoring, measurement and control, distributed multimedia stream synchronization, remote procedure call at-most-once transactions, research experiment setup, measurement and control, and cryptographic key management and lifetime control). In such situations, synchronization is typically provided by synchronizing a local clock of each relevant network element within the communications network to a reference time (e.g., Coordinated Universal Time or “UTC”) using one of several known techniques, protocols, and/or systems such as the network time protocol (NTP) or simple network time protocol (SNTP).
FIG. 1 illustrates a network time protocol framework according to the prior art. In the illustrated framework, a synchronization network is illustrated including one or more primary NTP time servers 100, each including a reference time source (not illustrated) such as a calibrated atomic clock or radio clock synchronized with a reference time (e.g., UTC), and a synchronization sub-network 108 including a larger number of secondary NTP time servers and/or secondary NTP time clients which obtain time data either from primary NTP time server 100 or other secondary NTP time servers. Synchronization between a reference time source and a given reference time may be obtained via any of a number of mechanisms including modem 102, satellite 104 (e.g., Global Positioning Service, Geostationary Operational Environment Satellite, Long Range Navigation “LORAN”, etc), and/or radio link 106 as shown or other conventional data communication mechanisms such as local or wide-area communications network(s) (not illustrated).
In the illustrated framework, time clients and time servers are categorized by “stratum”, the effective number of NTP “hops” between a time client or server and an authoritative reference time source. NTP time servers (e.g., primary NTP time servers 100) which are directly coupled to reference time sources are described as being stratum 1 network elements, NTP time clients 110a and NTP time servers 112a which obtain time data from stratum 1 network elements are described as being stratum 2 network elements, and so on from stratum 1 to stratum n as shown. In addition to this client/server mode of operation, time data may be transferred utilizing a symmetric mode, for example between same-stratum-level peer NTP time client(s) and/or server(s), to cross-check local clocks and mitigate errors due to equipment or propagation failures. Time data is transferred between NTP time clients and NTP time servers utilizing NTP messages which are exchanged by instantiations of the protocol machine known as “associations” within each client or server.
FIG. 2 illustrates an NTP time server synchronization process according to the prior art. In the illustrated process, time data is first received by an NTP time server either directly from a reference time source or from another NTP time server (e.g., via multicast, unicast, or anycast transmission of an NTP message) utilizing an IP version 6 (IPv6) transport (process block 200). Thereafter, a determination is made whether or not the received time data is to be transmitted via multicast or “broadcast” transmission (process block 202). If multicast transmission is to be used, a determination is then made whether a peer timer has expired (process block 204) signaling the NTP time server that the next multicast time data transmission should be sent. Once a determination is made that the peer timer has expired, a multicast NTP message is generated utilizing the previously received time data (process block 206) and transmitted to one or more NTP time clients utilizing an IPv6 transport (process block 208).
If the received time data is not to be transmitted by the NTP time server utilizing multicast transmission, a determination is made whether a time data request NTP message has been received (e.g., by unicast or anycast transmission) from an NTP time client (process block 210). Once a time data request has been received, a time data reply NTP message is generated utilizing the previously received time data (process block 212) and transmitted to the requesting NTP time client utilizing an IPv6 transport (process block 214). In another prior art NTP time server synchronization process (not illustrated), the process depicted by and described with respect to FIG. 2 is duplicated with the exception that time data is received by an NTP time server (see process block 200) and transmitted to one or more time clients (e.g., via multicast, unicast, or anycast transmission) (see process blocks 202 and 208) utilizing IP version 4 (IPv4).
NTP time clients utilize time data within transferred NTP messages to determine attributes such as clock offset, roundtrip delay, and dispersion for one or more associated NTP time servers which are used to select the most accurate NTP time server available for use in adjusting the NTP time client's local clock to bring it into correspondence with the reference clock. NTP messages are typically encapsulated within user datagram protocol (UDP) datagrams which are in turn encapsulated within Internet Protocol (IP) packets. The transfer of NTP messages and time data in conventional communications networks is therefore dependent on the network-layer protocol-implementation of each relevant NTP time server and NTP time client.
Consequently, while IPv4 only NTP time servers, which constitute the vast majority of available NTP time servers on the Internet, can provide time data to other IPv4 NTP time servers and NTP time clients, they cannot currently provide time data to NTP time clients and NTP time servers implementing other network-layer protocols such as IPv6. Consequently, IPv6 only NTP time clients and NTP time servers must currently obtain time data either from one or more of an extremely small number of publicly available IPv6 only NTP time servers as illustrated in FIG. 2 or by providing their own IPv6 primary NTP time server and associated reference time source. Drawbacks associated with these approaches include the reduced reliability and availability of existing IPv6 only NTP time servers as compared to existing IPv4 only NTP time servers due to their small number and the resulting potential for overburdening, the significant cost associated with obtaining an accurate reference time source, and the waste of resources associated with providing separate sets of IPv4 and IPv6 NTP time servers.